Enterprises today are in need of improved methods for managing user authentication and access. User authentication is the process whereby a first party's computer, computer program, or user attempts to confirm that a second computer, computer program or user from whom the first party has received a communication is the claimed second party. The process typically involves the authentication of the user's identity, which can be a password, account name, personal identification number, biometric identifier, permission level or other attribute identifying or pertaining to the user in some manner.
Historically, each application used a common security infrastructure. As a result, a user desiring access to multiple applications was required to provide multiple passwords which was both time intensive and unreliable. The solution was to develop a common enterprise security infrastructure to replace the heterogeneous infrastructure. One method of streamlining the authentication process is through single sign on (SSO), sometimes called “reduced sign on,” applications. These applications provide security and administrative management for Web applications with a centralized security infrastructure for managing user authentication and access. More specifically, SSO applications capture identification and authentication information once, and provide it to systems accessed by a user automatically. The objective of single sign-on systems is to reduce the user's number of different authenticators and to reduce the frequency with which the user must provide those authenticators to systems.
There are numerous benefits to implementing an SSO application. For the user, the benefits include the fact that there is only one authentication mechanism to remember and update, and one set of authentication rules. For the system administrators, the benefits include the fact that there is a single common registry of user information, a single method for managing user information, and a single security infrastructure. Finally, there is a benefit to the enterprise in the form of enhanced security because there is a single secure infrastructure leveraged throughout the enterprise that can be closely monitored and managed.
There are a number of different types of SSO applications in use today, including both those based on proprietary security systems and those based on recognized security standards. Proprietary systems were the first developed. In one of the earliest application, called an enterprise single sign on (also called a legacy single sign on) application, the application intercepts login prompts presented by secondary applications after the user is authenticated. The application then automatically fills in fields, such as a login ID or password, in the secondary applications. These products typically use some proprietary authentication mechanism and then reauthenticate transparently to multiple underlying systems through the user interfaces to those systems. This typically involves a scripting engine that drives the interaction with each underlying system's authentication mechanism. The scripting engine simulates a user logging in, so the underlying systems do not need to be changed. User names, passwords, and system information are stored in an SSO database.
The SSO database must follow all password rules for all enterprise systems and it must be updated whenever underlying passwords are changed. In addition, if the system or systems use other authentication mechanisms, such as certificates, challenge-response, or SecureID cards, those must be accommodated as well.
An alternative to enterprise single sign on is Web single sign-on works strictly with applications and resources accessed with a Web browser. In this application, access to Web resources is intercepted, either using a web proxy server or by installing a component on each targeted web server. Unauthenticated users who attempt to access a resource are diverted to an authentication service, and returned only after a successful sign-on. It is common to use cookies to track the user's authentication state, and the Web single sign on application extracts user identification information from these cookies, passing it into each Web resource.
As previously mentioned, there are a number of single sign on applications based on recognized standards such as Kerberos, Distributed Computing Environment, Microsoft ActiveDirectory and related technologies, and public key infrastructure. By way of example, Kerberos externalizes authentication entirely. The user signs into the Kerberos server and is issued a ticket which the client software presents to servers that the user attempts to access. Kerberos is available on Unix, Windows and mainframe platforms, but requires extensive modification of client/server application code, and is consequently not used by many legacy applications.
Finally, a number of SSO applications have been built on top of a common registry. Of course, using a common registry requires that all existing applications be migrated to use this new registry and that some department or external organization must manage this critical business system. In general, the best registry to choose is one that supports Lightweight Directory Access Protocol (LDAP). There are a number of LDAP server products, and most security and middleware products that support secure access can use an LDAP directory for authentication. Once an enterprise embarks on this effort, they may find that many applications can switch easily to LDAP simply by reconfiguring the middleware that they use. For example, Netscape Enterprise Server, Apache, IBM HTTP Server, AIX, Solaris, and WebSphere Application Server already support LDAP out of the box. Additionally, Microsoft ActiveDirectory can provide LDAP services to other clients.
The task of configuring an SSO system for a large enterprise with numerous existing systems can be substantial. Custom scripts must be developed for each user authentication interaction. With respect to only UNIX utilities, the list includes telnet, ftp, rsh, and rlogin. It is easy to see why, when this list is added to the lists of utilities for other operating systems, custom applications, and Web sites, the task of creating scripts, much less managing them, grows dramatically. In addition, these proprietary and standards-based solutions do not interoperate seamlessly. Accordingly, they cannot be applied to every system. The result is a complex system of integrating user authentications which leads to a costly solution for the enterprise.
Another problem inherent in SSO applications is the absence of password management features, such as the ability to lock, unlock, enable, and disable end user accounts. Because these are not part of the LDAP standard, password management features are not automatically incorporated into most SSO applications. Password management features are sometimes incorporated into SSO applications on a custom basis. Consequently, these features become proprietary to the SSO vendor and cannot be ported to other vendors' application.
Enterprises interested in robust password management features typically look to existing identity management application, such as Sun Microsystems' Identity Manager. These types of products provide a foundation for building reusable business processes for managing user data. They can be invoked by multiple actors in the system and provide a single source for password management across the enterprise. For example, many of these applications provide automated identity management services (creation, modification, and eventual deletion or suspension of user accounts and entitlements) for enterprise systems based upon the user's relationship with the firm, whether they are an employee, contractor, customer or business partner, and the specific entitlement policies of the organization.
While there are a number of identity management applications available, the applications are proprietary to each vendor and are not intended to integrate with one another. Moreover, the identity management applications are not inherently designed to operate in conjunction with other vendors' SSO applications. Consequently, an enterprise that is interested in a comprehensive application which incorporates single sign on functionality from one vendor with the features of an identity management application from another vendor must either develop a proprietary system or attempt to integrate two or more commercially available applications together. This can be a daunting task for even the most sophisticated enterprise.
There is a need, therefore, for a vendor-agnostic method of integrating single sign on functionality with the features of a robust identity management application in a cost effective, reliable and timely manner.
There is also a need for a method of integrating single sign on applications with identity management applications which reduces the cost and complexity of application development.
There is also a need for a method of restricting user access through a single sign on application that is platform independent, thereby reducing the time, cost and complexity associated with utilizing disparate tools for different platforms.
There is also a need for a method of authenticating user identities that allows developers, designers and system administrators to use languages and concepts with which they are comfortable.